// Copyright 2013 Petar Maymounkov
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

package zutil

/*

From Zookeeper doc (http://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html):

	+ When a client (session) becomes partitioned from the ZK serving cluster it will
	begin searching the list of servers that were specified during session
	creation. Eventually, when connectivity between the client and at least one of
	the servers is re-established, the session will either again transition to the
	"connected" state (if reconnected within the session timeout value) or it will
	transition to the "expired" state (if reconnected after the session timeout).
	It is not advisable to create a new session object (a new ZooKeeper.class or
	zookeeper handle in the c binding) for disconnection. The ZK client library
	will handle reconnect for you. In particular we have heuristics built into the
	client library to handle things like "herd effect", etc... Only create a new
	session when you are notified of session expiration (mandatory).

	+ |— DISCONNECTED —> CONNECTED —> DISCONNECTED —> EXPIRED —> ···

	+ Watches are maintained locally at the ZooKeeper server to which the
	client is connected. This allows watches to be light weight to set,
	maintain, and dispatch. When a client connects to a new server, the watch
	will be triggered for any session events. Watches will not be received
	while disconnected from a server. When a client reconnects, any previously
	registered watches will be reregistered and triggered if needed. In general
	this all occurs transparently. There is one case where a watch may be
	missed: a watch for the existance of a znode not yet created will be missed
	if the znode is created and deleted while disconnected.

	+ An optional "chroot" suffix may also be appended to the connection
	string. This will run the client commands while interpreting all paths
	relative to this root (similar to the unix chroot command). If used the
	example would look like: "127.0.0.1:4545/app/a" or
	"127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002/app/a" where the client would
	be rooted at "/app/a" and all paths would be relative to this root.

*/
